前言

第二個重要事件，來談談我們評估更換 CDN 廠商的事件。相較於 ISO 27001 ，這個事件應該可以算是真正的單一事件了，因為評估以及實際搬家完就相當於是整個事件告一個段落。

事實上，這個事件在筆者寫文章的當下也還在進行中，算是滿新的一個事件。此外，這個事件也算是筆者接下來最大的幾個任務之一，其中對於 CDN 相關的知識，筆者其實也都是從頭開始理解。這與之前重大 P0 事件系列的〈倒站又不倒站〉類似，都是在事件發生之後，才開始深深感到自己知識量的不足。

因此，在分享的最後，筆者一樣會稍微介紹一些在這個事件中有學習到的技術知識，也希望可以對讀者有一些幫助。

背景故事

會想要評估這次的更換，最主要還是為了省錢的關係。因為原本的廠商是一家全球知名且非常大的公司，服務本身自然沒有問題，但相對而言價格就比較硬一些。而另一方面，雖然確認過新廠商應該會比較省錢，但也會需要確認一些設定是否能夠符合原本的預期。

比如說，因為該專案主要也是一個 B2B 的產品，而我們是透過 Origin 的傳輸量來與客戶報價，因此相關的報表就變得非常重要。我們期待 CDN 的報表不能差太多，或至少客戶所在意的重點不能被修改。換個話說，筆者的評估工作，其中一個就是在發現報表完全不符合客戶需求的時候，做出「留在原本廠商」的決定。

此外，在舊廠商所遇到的痛點，比如 TLS 憑證的驗證等級是比較麻煩的 Organization Validation (OV) 而且無法每年自動更新；或是報表的派送無法保證當天會出現，而是三天內才會出現之類的問題，都會是在新的廠商中期待可以改善的事項。

最後，所有研究都要在下次合約更換之前完成，並行要預留實際搬遷和測試的時間。

任務拆解

因為這會是一個非常大的工作，因此得到任務後，首先要釐清並拆解明確的待辦事項。

首先，為了在新的服務上測試，筆者會要先嘗試完成透過新的 CDN 服務串接原本 Origin 的工作。在串接的過程中，要同時確認一些原本的要求是否能達成(比如會用到 TLS 憑證的時候要一併確認是否能夠自動更新)。串接完後，要嘗試生產報表並確認報表是否符合預期。如果一切順利，那就要接著制定具體的搬遷和測試計畫。

換句話來說，按照順序主要是以下三件任務：

1. 串接
2. 產報表並評估內容
3. 實際搬遷與測試

實作過程

串接

串接是一個比預期還要困難上許多的工作，但因為對方專為此派了一位與筆者接洽的工程師，因此在對方的幫助下，其實省下了不少時間。

不過，筆者仍然花了非常多時間在嘗試理解原本的 CDN 設定。這其中包含了 DNS 的 routing 因為舊廠商設定的關係，因此多繞了一層的 DNS；另外也因為想要節省 TLS 憑證的關係，有使用了 multi-domain，或說有應用到 Subject Alternative Name (SAN) 的技術，也就是屬個 domain 共用同一個 TLS 憑證，以此來避開每個 domain 都要申請一個 TLS 憑證的方式。關於這部分，筆者都是從頭開始學習後，才漸漸比較能理解這一塊的設定原理，但也因為前人幾乎沒有留下文件的關係，其實撞了不少次設定問題後才解決。

此外，新廠商的 CDN 因為也有一些該廠商的 feature ，因此也無法完全把原本理解的設定照搬過去。比如在 multi-domain 的設定中，新廠商有一套底層可能走一樣的邏輯，但在設定上比較特別的方式，這一塊就必須透過反覆的溝通才能完成。另外，CDN 快取的規則在設定上因為也有相當大的差異，因此也花了很長的時間在終於造一個段落。

當然，還是有一些在設定上幾乎相同的事情。比如以 AWS S3 的內容做為 origin 的時候，都需要提供一組 AWS credentials 給對方進行他們後台的測試與串接。這個部分在理解上就沒有造成太大的困難。

報表

報表可以說是技術上最困難的部分。因為在一般的 CDN 報表中，通常只會提供一份表格形式的 csv 檔案。將這份 csv 檔案視覺化成類似原本的形式比想像中還要難上許多，而即使能透過 Grafana 做到這件事，要串接成固定派發的形式也是一個挑戰。

雖然這部分的研究主要是對方與筆者的接洽的工程師在研究，但跟據他分享的文件，這裡也許要花上至少兩週以上的時間全力研究才行。在途中也還會需要向產品經理提供範例資料，以利他們與客戶談判在新廠商的計費方式。

幸運的是，在談判的過程中，我們意外發現客戶其實並不在意圖表，他們比較在意的主要是內容本身。也就是說，因為 csv 檔案有包含他們需要的資訊，因此他們其實是可以接受的。既然如此，視覺化這項大工程的研究成本就得以因此而省下來。

資源分配

雖然與技術研究無關，但在整個研究過程中還有遇到一些小插曲。可能是因為時程上比較匆忙，或可能一開始沒有討論清楚的關係，公司在筆者已經研究到一半的時候，認為在還沒與客戶確認意向的情況下，貿然投入人力研究會有後續人力浪費掉的可能性，因此筆者在研究到一半的時候收到了暫時中止的指令。

不過，基於某些研究需要先告一個段落，否則後續難以銜接的問題，因此最後仍然有討論出一個目前的研究中止點與時間規劃。具體內容就是先完成串接和報表的研究，但同時也要評估後續搬遷與測試的工作量，並提出可能的規劃，再跟據與客戶的談判結果來決定下一步。

在筆者撰寫的當下，事實上也還不確定接下來是否會繼續做下去。但即使不會做下去，筆者也認為已經有足夠多的技術學習筆記可以向各位分享，就留到下一篇吧。